Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: support for Service Discovery Across Multiple Nacos Clusters #10950

Closed
wants to merge 30 commits into from

Conversation

ShenFeng312
Copy link
Contributor

@ShenFeng312 ShenFeng312 commented Feb 21, 2024

Description

Fixes #10799

Checklist

  • I have explained the need for this PR and the problem it solves
  • I have explained the changes or the new features added to this PR
  • I have added tests corresponding to this change
  • I have updated the documentation to reflect this change
  • I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

@shreemaan-abhishek
Copy link
Contributor

please fix the linter

@monkeyDluffy6017 monkeyDluffy6017 changed the title feat: Support for Service Discovery Across Multiple Nacos Clusters feat: support for Service Discovery Across Multiple Nacos Clusters Feb 23, 2024
@ShenFeng312
Copy link
Contributor Author

@monkeyDluffy6017 hello~ These errors seem to be unrelated to this PR.

@monkeyDluffy6017
Copy link
Contributor

Could you add test cases to cover this?

@ShenFeng312
Copy link
Contributor Author

Could you add test cases to cover this?

I will add test cases next week

@zll600
Copy link
Contributor

zll600 commented Feb 27, 2024

@monkeyDluffy6017 hello~ These errors seem to be unrelated to this PR.

The ci problem has been fixed by #10959. Please merge latest master.

@shreemaan-abhishek
Copy link
Contributor

CI is still failing

@ShenFeng312
Copy link
Contributor Author

image
@shreemaan-abhishek hello~ i dont know how to fix this error

@shreemaan-abhishek
Copy link
Contributor

@ShenFeng312 try using --- response_body chomp

@ShenFeng312
Copy link
Contributor Author

please pay attention here: #10950 (comment)

fixed

@shreemaan-abhishek
Copy link
Contributor

shreemaan-abhishek commented Apr 29, 2024

can you also mention that host is deprecated now (both in code and docs). Here is an example:
image

https://apisix.apache.org/docs/apisix/plugins/kafka-logger/#attributes

@ShenFeng312
Copy link
Contributor Author

can you also mention that host is deprecated now (both in code and docs). Here is an example: image

https://apisix.apache.org/docs/apisix/plugins/kafka-logger/#attributes

Yes

@shreemaan-abhishek
Copy link
Contributor

I think this line is enough: 6d2dcc2?diff=split&w=0#diff-8d872babc717e9d733641b56bfc530ef98751fbe4e68f08d79b2b83109c22fffR302

we can skip these:
image

And it think it's better if the comment says: "deprecated, use nacos.hosts instead"

apisix/discovery/nacos/init.lua Outdated Show resolved Hide resolved
local query_path = instance_list_path .. service_info.service_name
.. token_param .. namespace_param .. group_name_param
.. signature_param
.. token_param .. namespace_param .. group_name_param
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are many other whitespace changes like this, please revert them

@@ -405,12 +434,17 @@ function _M.init_worker()
return
end

default_weight = local_conf.discovery.nacos.weight
log.info('default_weight:', default_weight)
--default_weight = local_conf.discovery.nacos.weight
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why change these?

Copy link
Contributor Author

@ShenFeng312 ShenFeng312 May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because default_weight in different nacos may different @shreemaan-abhishek

local fetch_interval = local_conf.discovery.nacos.fetch_interval
log.info('fetch_interval:', fetch_interval)
access_key = local_conf.discovery.nacos.access_key
secret_key = local_conf.discovery.nacos.secret_key
--access_key = local_conf.discovery.nacos.access_key
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

Copy link
Contributor Author

@ShenFeng312 ShenFeng312 May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because access_key and secret_key in different nacos may different @shreemaan-abhishek

@@ -109,6 +109,7 @@ services:
- consul.cluster

## Nacos cluster

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this change is not needed

Copy link
Contributor

@bzp2010 bzp2010 Jul 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 Please try to avoid unnecessary formatting changes, such as adding or reducing blank lines.

host:
- "http://192.168.33.1:8848"
hosts:
- host:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this doesn't seem the right way. I think the following is better:

nacos:
  hosts:
    - xyz
    - abc

Copy link
Contributor Author

@ShenFeng312 ShenFeng312 May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean to configure it like this?

hosts:
  name1:
    - host:
       - xxx
  name2:
    - host:
       - xxx

@shreemaan-abhishek we may need config different access_key in different nacos

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with @ShenFeng312, multiple nacos instances will be used in a multi-cluster environment (with multiple registries), not just for load balancing on a single endpoint.

@ShenFeng312
Copy link
Contributor Author

Hello, can I continue with this PR? Or do I need to create a new one? Or are we not planning to support this feature? @shreemaan-abhishek

@bzp2010
Copy link
Contributor

bzp2010 commented Jul 13, 2024

I think this really should go on, let me see. No new PR is needed and I am open to adding this feature, we can do that.

Comment on lines +437 to +438
--default_weight = local_conf.discovery.nacos.weight
--log.info('default_weight:', default_weight)
Copy link
Contributor

@bzp2010 bzp2010 Jul 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be deleted? Delete them if they are no longer used.

Comment on lines +446 to +447
--access_key = local_conf.discovery.nacos.access_key
--secret_key = local_conf.discovery.nacos.secret_key
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete them if they are no longer used too.

Comment on lines +385 to 391
fetch_from_naocs(local_conf.discovery.nacos)
local others_nacos = local_conf.discovery.nacos.hosts
if others_nacos and #others_nacos > 0 then
for _, nacos in ipairs(others_nacos) do
fetch_from_naocs(nacos)
end
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old mode will be deprecated later right?
Should we treat them as mutually exclusive now (i.e. disable single registry mode when multiple registries mode are enabled), I think it's clearer for the user rather than mixing them up and suddenly not working anymore when we remove it.

Comment on lines +317 to +318
local signature_param = get_signed_param(service_info.group_name,
service_info.service_name, nacos)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
local signature_param = get_signed_param(service_info.group_name,
service_info.service_name, nacos)
local signature_param = get_signed_param(service_info.group_name,
service_info.service_name, nacos)

local nacos_name_from_args = (up.discovery_args and up.discovery_args.name)
or default_nacos_name
local nacos_name = nacos.name or default_nacos_name
if nacos_name ~= nacos_name_form_args then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if nacos_name ~= nacos_name_form_args then
if nacos_name ~= nacos_name_from_args then

A typo here.

if not applications or not applications[namespace_id]
or not applications[namespace_id][group_name]
if not applications or not applications[nacos_name]
or not applications[nacos_name][namespace_id]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
or not applications[nacos_name][namespace_id]
or not applications[nacos_name][namespace_id]

@@ -54,6 +54,49 @@ return {
},
access_key = {type = 'string', default = ''},
secret_key = {type = 'string', default = ''},
hosts = {
Copy link
Contributor

@bzp2010 bzp2010 Jul 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe like https://github.com/apache/apisix/blob/master/apisix/discovery/kubernetes/schema.lua#L114-L216 would be a better way? Users have the option to continue using the single registry mode, or switch to the multi-registry mode altogether.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we change the configuration file to the above format, the redundant nesting called hosts is unnecessary, i.e. the configuration should be:

discovery:
  nacos:
    host: xxx

Or,

discovery:
  nacos:
    - id: default
      host: xxx
    - id: test
      host: xxx

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great!

Comment on lines +227 to +228
local nacos_name_from_args = (up.discovery_args and up.discovery_args.name)
or default_nacos_name
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember other service discovery implementations using different rules on service name to handle multiple registries instead of using discovery_args, please follow that similar.

https://apisix.apache.org/docs/apisix/discovery/kubernetes/#multi-cluster-mode-query-interface

# host: # Nacos address(es)

# nacos:
# name: "default" # Deprecated,see nacos.hosts.name
Copy link
Contributor

@bzp2010 bzp2010 Jul 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The single-registry mode that is now supported does not require a name, and I think your defaults in the code can handle that scenario.
So this is not required and should be removed.

# access_key: "" # Deprecated see nacos.hosts.access_key
# secret_key: "" # Deprecated see nacos.hosts.secret_key
# hosts:
# - name: "your_nacos_cluster_name" #your nacos cluster name
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The field used to identify the registry should be id not name. please follow the existing rules unless you are the first to do so.

# - id: release # a custom name refer to the cluster, pattern ^[a-z0-9]{1,8}

Comment on lines +35 to +54
host:
- "http://127.0.0.1:8858"
prefix: "/nacos/v1/"
fetch_interval: 1
weight: 1
timeout:
connect: 2000
send: 2000
read: 5000
hosts:
- name: nacos3
host:
- "http://127.0.0.1:8868"
prefix: "/nacos/v1/"
fetch_interval: 1
weight: 1
timeout:
connect: 2000
send: 2000
read: 5000
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think a mixed mode of single registry and multiple registries should exist, and the user should explicitly choose one or the other. This will also simplify our testing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you propose removing host and introduce hosts as it's replacement? It would be a breaking change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shreemaan-abhishek I am proposing: anyOf host or hosts, and prohibits the mixing of the two modes, so the following configuration is acceptable.

discovery:
  nacos:
    host: xxx
    prefix: xxx

Or,

discovery:
  nacos:
    - id: default
      host: xxx
      prefix: xxx
    - id: backup
      host: xxx
      prefix: xxx

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this is much better. cc: @ShenFeng312

@bzp2010
Copy link
Contributor

bzp2010 commented Jul 13, 2024

@ShenFeng312 Except for a few minor issues that could be modified, this is an excellent job.

Copy link

github-actions bot commented Oct 3, 2024

This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 4 weeks if no further activity occurs. If you think that's incorrect or this pull request should instead be reviewed, please simply write any comment. Even if closed, you can still revive the PR at any time or discuss it on the [email protected] list. Thank you for your contributions.

@github-actions github-actions bot added the stale label Oct 3, 2024
Copy link

This pull request/issue has been closed due to lack of activity. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.

@github-actions github-actions bot closed this Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

feat: Support for Service Discovery Across Multiple Nacos Clusters
5 participants